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Be s chre ibung 

Verfahren zum Betrieb einer industriellen Steuerung 

5 Die Erfindung bezieht sich auf ein Verfahren zum Betrieb ei- 
ner industriellen Steuerung, insbesondere fur Produktionsma- 
schinen . 

Ferner bezieht sich die Erfindung auf eine industrielle Steu- 
10 erung zur Durchfuhrung des erf indungsgemafien Verf ahrens . 

Es ist heutzutage ublich, sowohl fur die speicherprogrammier- 
bare Steuerung (SPS) als auch fur die Bewegungs steuerung (MC) 
jeweils unterschiedliche hierarchische Ablaufebenen zu model- 
15 lieren, denen Software-Tasks zur Steuerung des jeweiligen 

technischen Prozesses zugeordnet werden. Diese Tasks konnen 
Systemauf gaben erfullen, sie konnen aber auch anwenderpro- 
grammiert sein. 

20 Aus DE 197 40 550 Al ist es bekannt, dass Prozesssteuerungs- 
funktionalitaten der speicherprogrammierbaren Steuerungen 
"SPS" und Bewegungsfunktionalitaten von MC- Steuerungen in ei- 
nem einheitlichen konf igurierbaren Steuerungssystem integ- 
riert werden konnen. 

/ 25 

i Diese SPS/MC-Integration geschieht in Form des Zusammenschal- 

tens von SPS- und MC-Steuerungsbaugruppen . Bei einer solchen 
Ausfuhrung der Integration wird aber keine optimale und effi- 
ziente Tasks truktur fur die Gesamtheit der Steuerungsauf gaben 

3 0 erreicht. AuSerdem werden bei dieser Art der Integration 

hauptsachlich die klassischen MC-Funktionalitaten, wie sie 
insbesondere fur Werkzeugmaschinen relevant sind, unter- 
stutzt. Anf orderungen an die Steuerung, wie sie aus dem Be- 
trieb von Produktionsmaschinen bekannt sind, werden durch 

3 5 diese Art des Zusammenschaltens von SPS- und MC-Steuerungs- 
baugruppen nicht optimal unterstiitzt. 
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Aus EP 0 73 5 445 A2 ist es bekannt, zum Betrieb einer Werk- 
zeugmaschine oder eines Roboters einen gesonderten Wartebe- 
fehl (WAIT) zu gebrauchen. Der hier beschriebene Wartebefehl 
(WAIT) unterstutzt aber insbesondere die Steuerung von Pro- 
5 duktionsmaschinen noch nicht optimal. 

In der Anmeldung DE 19 93 19 33.2 wird vorgeschlagen, den 
Takt des Kommunikat ions systems zwischen dem PC-System und den 
peripheren Geraten fur einen Wechsel zwischen einem Echtzeit- 

10 betriebsprogramm und einem Nicht-Echtzeitbetriebsprogramm 
heranzunehmen. Hier ist es aber die Aufgabe dieser Taktab- 
greifung aus dem Kommunikationssystem, in einem industriellen 
^J) Prozess einen moglichst reibungslosen Wechsel zwischen Echt- 
zeit- und Nicht-Echtzeitanwendungen stattfinden zu lassen. 

15 Bei dieser Ausgestaltung wird der Grundtakt aber nur aus dem 
Takt des Kommunikat ionsmediums abgeleitet und er wird nur fur 
den Wechsel des Betriebssystemmodus eines PC-Systems verwen- 
det . 

20 Der Erfindung liegt daher die Aufgabe zugrunde, fur jeweils 
unterschiedliche Steuerungsauf gaben und unterschiedliche 
Randbedingungen bzw. Anf orderungen des zugrunde liegenden 
technischen Prozesses in einfacher Weise optimale Auspragun- 
gen einer industriellen Steuerung zu erstellen, die sowohl 
v 25 SPS- als auch MC-Funktionalitat zur Verfugung stellt und so- 
^ mit auch fur die Steuerung von Produktionsmaschinen geeignet 
ist. 

Diese optimalen Auspragungen werden prinzipiell zum einen 
3 0 durch ein einheitliches konf igurierbares Ablauf ebenenmodell 

fur die Steuerungs -Tasks der industriellen Steuerung erreicht 
und zum anderen durch Mechanismen (Wait„f or_Condition- 
Befehl) , die es einem Anwender ermoglichen, im Programmf luss 
auf beliebige Bedingungen zu warten und hoherprior zu reagie- 
3 5 ren. 
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Von diesem Ansatz ausgehend wird die oben genannte Aufgabe 
dadurch gelost, dass Mechanismen bereitgestellt sind, die es 
einem Anwender ermoglichen im Programmflufi auf eine beliebige 
Bedingung zu warten, wobei bei Erfiilltsein der Bedingung der 
5 ProgrammfluS unmittelbar fortgesetzt wird, bei Nichterf iillt- 
sein der Bedingung der Programmf lufi solange angehalten wird, 
bis das Erfiilltsein der Bedingung festgestellt wird, wobei 
beim Warten auf das Erfiilltsein der Bedingung die Prioritat 
der Bedingungsuberpriifung im Vergleich zur aktuellen Taskpri- 

10 oritat erhoht wird. Durch diesen Mechanismus wird es ermog- 
licht, eine zusammengehorige und geschlossene Auf gabenstel- 
lung in einem Stuck Code eines Anwenderprogr amines auszudrii- 
cken, ohne dass weitere Mechanismen wie z.B. Event-Handler 
erforderlich sind. Ein Anwender kann somit in einem sequen- 

15 tiellen Programmablauf auf einer relativ niedrigen Priori- 
tatsebene einer "Motion Task" durch Programmkonstrukte in 
seinem Programmflufi (Anwenderprogramm) das Warten auf 
hochpriore Ereignisse formulieren, ohne in ein anderes Pro- 
gramm wechseln zu miissen. Dadurch wird einerseits in der 

2 0 Steuerung Verwaltungs -Overhead vermieden, was direkt die Sys- 

tem-Performance erhoht und andererseits aus programmiertech- 
nischer Sicht das Lokalitatsprinzip unterstutzt, wodurch z.B. 
das Debugging erleichtert wird. 

( 2 5 Der beschriebene Mechanismus und der dazugehorige Befehl wer- 
^ den im weiteren als "wait_f or_condition" bezeichnet. 

Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfin- 
dung liegt darin, dass nach dem Erfiilltsein der Bedingung die 

3 0 folgende Programmsequenz bis zu einem expliziten Ende hoch- 

prior bearbeitet wird, wobei nach dem expliziten Ende der 
Programmsequenz die alte Taskprioritat wieder aufgenommen 
wird. Dadurch wird eine hohe Deterministik in der Sequenz 
"Warten auf externes Ereignis" und der "Aktion, die nach die- 
35 sem Ereignis folgt", z.B. Korrekturbewegungen bei einer 

Druckmarkensynchronisation, erreicht. Ein Anwender hat somit 
die Moglichkeit sich in seinen Programmen temporar auf eine 
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hohe Prioritatsebene zu legen und dabei deterministische Vor- 
gange leicht und elegant beschreiben zu konnen. Anwendungs- 
beispiele sind z.B. Druckmarkensynchronisation und schnelle 
Bewegungs start (beispielsweise nach Flankenwechsel ) . 

5 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass fur die Formulierung der Bedingungen ProzeSsigna- 
le und/oder interne Signale der Steuerung und/oder Variablen 
aus Anwenderprogrammen verwendet werden. Dadurch ist es dem 
10 Anwender moglich, bei der Beschreibung der Bedingungen in ei- 
ner einheitlichen Weise neben Anwenderprogrammvariablen auch 
direkt Systemzustande und ProzeSsignale zu verwenden. 

> 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
15 darin, dass die Bedingungen logische und/oder arithmetische 
und/oder beliebige funktionelle Verknupf ungen enthalten. Da- 
mit ist es dem Anwender moglich, innerhalb einer Anweisung 
komplexe Synchronisationsbeziehungen zu spezif izieren . 

2 0 Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 

darin, dass ein Anwenderprogramm fur den Betrieb der Steue- 
rung mehr als einen solchen Mechanismus enthalt. Dadurch wer- 
den bei der Programxnierung der Anwendungen die Flexibilitat 
und die Moglichkeiten des Anwenders insbesondere hinsichtlich 
25 der Beschreibung von Synchronisationsaktivitaten erhoht. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass es mehrere Anwenderprogramme beim Betrieb der 
Steuerung geben kann, die diese Mechanismen enthalten. Da- 

3 0 durch werden bei der Programmierung der Anwendungen die Fle- 

xibilitat und die Moglichkeiten des Anwenders insbesondere 
hinsichtlich der Beschreibung von Synchronisationsaktivitaten 
erhoht . 

3 5 Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 

darin, dass der jeweilige Mechanismus einem Anwender in einem 
Anwenderprogramm als ubliches programmiersprachliches Kon- 
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strukt zur Verfugung steht. Der "wait__f or_condition-Bef ehl " , 
der diesen Mechanismus auslost, kann somit von einem Anwender 
in den Anwenderprogrammen z.B. wie eine while-Schleif e ver- 
wendet werden, wodurch die Programmers t el lung sehr erleich- 
5 tert wird. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass das Runtime-System der Steuerung ein Ablaufebe- 
nenmodell enthalt, das mehrere Ablaufebenen unterschiedlichen 
10 Typs mit unterschiedlicher Prioritat aufweist, wobei folgende 
Ablaufebenen vorgesehen sind: 

rf a) eine Ebenengruppe mit synchron getakteten Ebenen, beste- 
hend aus mindestens einer Systemebene und mindestens ei- 
15 ner Anwenderebene, wobei die Ebenen dieser Ebenengruppe 

untereinander eine Priorisierung aufweisen konnen, 



b) einer Anwenderebene fur Systemexceptions 

2 0 c) einer zeitgesteuerten Anwenderebene 

d) einer ereignisgesteuerten Anwenderebene 

e) einer sequentiellen Anwenderebene 



f) einer zyklischen Anwenderebene, 
wobei Anwenderebenen der Ebenengruppe a) optional synchron zu 
einer der Systemebenen der Ebenengruppe a) laufen konnen. Ein 
wesentlicher Vorteil dieser Schichtung liegt darin, dass die 
3 0 Kommunikation zwischen den Tasks der Prozesssteuerung (SPS) 
und denen der Bewegungs steuerung (MC) minimiert wird. Ein 
weiterer Vorteil liegt darin, dass die Programmierung der 
Steuerungsaufgaben fur die Prozesssteuerung und fur die Bewe- 
gungs steuerung in einer einheitlichen Programmiersprache mit 
3 5 einer einheitlichen Erstelloberf lache erfolgen kann und dass 
der Anwender ein fur seine jeweiligen Anf orderungen zuge- 
schnittenes Ablauf ebenenmodell flexibel erstellen kann. 
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Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass der Grundtakt des Ablauf ebenenmodells aus einem 
internen Timer oder aus einem internen Takt eines Kommunika- 
5 tionsmediums oder aus einem externen Gerat oder von einer 

GroSe, die zum technologischen ProzeS gehort abgeleitet wird. 
Dadurch kann sehr flexibel und sehr einfach der Grundtakt fur 
das Ablauf ebenenmodell abgeleitet werden. Dadurch, dass der 
Grundtakt fur das Ablauf ebenenmodell auch von einer GroSe, 
10 die zum technologischen Prozess gehort, ableitbar ist, kann 
auf eine sehr einfache Weise eine direkte Riickkopplung aus 
dem technologischen Prozess zur Steuerung erhalten werden. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
15 darin, dass die zeitgesteuerte Anwenderebene , die ereignisge- 
steuerte Anwenderebene, die sequent ielle Ablauf ebene, die 
zyklische Hintergrundebene und die Anwenderebene fur System- 
exceptions optional sind. Der Anwender kann sich dadurch sehr 
flexibel eine Steuerung erstellen, die fur seine konkreten 

2 0 vorliegenden Anf orderungen sehr effizient ist und die die ge- 

rade benotigten Ablaufebenen enthalt und somit keinen unnoti- 
gen Overhead beinhaltet. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
25 darin, dass die synchronen Ebenen zum Grundtakt ubersetzt 
^ und/oder untersetzt und/oder im Verhaltnis 1:1 getaktet sind. 
Dadurch konnen die Ebenen jeweils sehr leicht zu einem Viel- 
fachen des Grundtaktes getaktet werden oder aber auch jeweils 
zu einem reziproken Vielfachen getaktet werden. Ausgehend von 

3 0 einer gemeinsamen AusgangsgroSe konnen somit sehr einfach U- 

bersetzungen, aber auch Untersetzungen fur die jeweiligen E- 
benen erreicht werden. 



35 



Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass weitere priorisierende Schichtungen innerhalb der 
Ablaufebenen vorgesehen sind. Die Softwares truktur der indus- 
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triellen Steuerung lasst sich dadurch optimal an die unter- 
schiedlichen Steuerungsauf gaben bzw. an die Anf orderungen des 
zugrunde liegenden technischen Prozesses anpassen. Somit las- 
sen sich z.B. unterschiedliche Fehlerursachen unterschiedli- 
5 chen Ebenen mit z.B. auf steigender Prioritat zuordnen. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass optional Anwendertasks beim Systemhochlauf 
und/oder beim Systemrunterf ahren durchlaufbar sind. Dadurch 
10 konnen beim Systemhochlauf z.B. Initialisierungsf unktionen 

angestoSen werden oder beim Systemrunterf ahren wird sicherge- 
stellt, dass die im System vorhandenen Achsen eine definierte 
Position einnehmen. 

15 Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass in die Anwenderebenen Anwenderprogramme ladbar 
sind, die je nach Typ der Anwenderebene zyklusorientiert oder 
sequentiell programmiert sind. Dadurch kann der Anwender in 
seinen Anwenderprogrammen die Funktionalitat der Steuerung 

20 sehr flexibel an die zugrunde liegenden Anf orderungen des 

technischen Prozesses anpassen und er kann auch die Anwender- 
programme in unterschiedliche Anwenderebenen laden, urn da- 
durch eine fur seine jeweiligen Applikationen effektive Aus- 
pragung der Steuerung zu erreichen. Ein weiterer Vorteil 

25 liegt darin, dass der Anwender in ein einheitliches Ablauf- 
^ ebenenmodell bzw. Run time -System einer industriellen Steue- 
rung sowohl zyklusorientierte Anwenderprogramme als auch er- 
eignisorientierte Anwenderprogramme laden kann. Ein Anwender 
kann somit nach unterschiedlichen Paradigmen programmierte 
- 3 0 Programme (zyklusorientiert fur SPS-Funktionalitat und ereig- 
nisorientiert bzw. sequentiell fur Bewegungsf unktionalitat ) 
sehr flexibel und konform in die Anwenderebenen des Ablauf- 
ebenenmodells hinzuladen . 

3 5 Ein Ausfuhrungsbeispiel der Erfindung ist in der Zeichnung 
dargestellt und wird im folgenden erlautert. 
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Dabei zeigen: 

FIG 1 die wesentlichen Ablaufebenen einer klassischen 

speicherprogrammierbaren Steuerung , 

FIG 2 die wesentlichen Ablaufebenen einer Bewegungssteue- 

rung, 

FIG 3 schematische Darstellung einer industriellen Steue- 

1 0 rung , 



30 



FIG 4 das Ablauf ebenenmodell der erf indungsgemafien indus- 

triellen Steuerung, 



15 FIG 5 ein Ausf uhrungsbeispiel fur das Zuladen von Anwen- 

derprogrammen in die Anwenderebenen, 

FIG 6 ein Ausf uhrungsbeispiel fur den Gebrauch und den 

Mechanismus des Wait_f or_ Condition-Bef ehls , im Ab- 
20 lauf ebenenmodell der erf indungsgemaSen industriel- 

len Steuerung, 

FIG 7 ein weiteres Ausf uhrungsbeispiel fur den Gebrauch 

und den Mechanismus des Wait_f or_Condition-Bef ehls , 
25 im Ablauf ebenenmodell der erf indungsgemafien indus- 

^ triellen Steuerung, 

FIG 8 die syntaktische Beschreibung des 

Wait_f or_Condition-Bef ehls in einem Syntaxdiagramm, 



FIG 9 ein Beispiel fur die Formulierung einer Expression 

in programmiersprachlicher Notation und 



FIG 10 

35 



in einer Schemadarstellung Moglichkeiten, wie der 
Grundtakt fur die industrielle Steuerung gewonnen 
wird. 
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In der Darstellung gemaS FIG 1 sind die wesentlichen Ablauf- 
ebenen einer klassischen speicherprogrammierbaren Steuerung 
(SPS), angeordnet nach ihrer Prioritat, gezeigt. Der Priori- 
tatsanstieg ist dabei durch einen Pfeil symbolisiert . In der 
5 niederpriorsten Ebene werden, wie durch eine gestrichelte Li- 
nie angedeutet, zwei unterschiedliche Aufgaben, namlich ein 
freier Zyklus, d.h. " Anwenderebene freier Zyklus" und eine 
Hintergrund-Systemebene, d.h. " Systemebene Hintergrund" abge- 
wickelt. Der Hintergrund-Systemebene sind z.B. Kommunikati- 

10 onsaufgaben zugeordnet . Bei einer folgenden Anwenderebene, 

bezeichnet als "Anwenderebene zeitgesteuert " , ist der Aufruf- 
takt der Tasks bzw. der Programme dieser Ebene parametrier- 
bar. Es erfolgt eine Uberwachung dahingehend, ob die Bearbei- 
tung eines Anwenderprogrammes dieser getakteten Ebene recht- 

15 zeitig abgeschlossen ist, bevor das Startereignis erneut auf- 
tritt. Lauft die Taktzeit ab, ohne dass das Anwenderprogramm 
der zugeordneten Ebene fertig abgearbeitet ist, wird eine 
entsprechende Task einer prioritatsmaSig ubernachsten "Anwen- 
derebene fur asynchrone Fehler" gestartet. In dieser "Anwen- 

2 0 derebene fur asynchrone Fehler" kann der Anwender die Behand- 

lung von Fehlerzustanden ausprogrammieren . 

Auf die "Anwenderebene zeitgesteuert" folgt eine "Anwender- 
ebene Events". Die Reaktion auf externe oder interne Ereig- 
nisse (Events) erfolgt innerhalb der "Anwenderebene Events". 
A 2 5 Ein typisches Beispiel fur ein solches Ereignis ist das 

Schalten eines binaren bzw. digitalen Eingangs, wodurch typi- 
scherweise ein Ereignis ausgelost wird. In einer "Systemebene 
hochprior" liegen die Aufgaben des Betriebssystems , welche 
die Arbeitsweise der programmierbaren Steuerung (SPS) sicher- 
30 stellen. 

Die Darstellung gemafi FIG 2 zeigt die wesentlichen Ablaufebe- 
nen einer Bewegungs steuerung (MC) . Auch hierbei sind die ein- 
zelnen Ebenen nach ihrer Prioritat hierarchisch, wie durch 

3 5 einen Pfeil symbolisiert, angeordnet. Eine "Systemebene Hin- 

tergrund" und eine "Anwenderebene sequentiell" haben eine 
gleiche Prioritat, namlich die niedrigste. Diese aufgabenma- 
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Sige Zugehorigkeit ist wie bei FIG 1 durch eine gestrichelte 
Linie symbolisiert . Die Tasks der "Anwenderebene sequentiell " 
werden zusammen mit den Tasks der " Systemebene Hintergrund" 
im Round-Robin-Verf ahren abgearbeitet . Typische Tasks der 
5 "Systemebene Hintergrund" sind z.B. solche fur Kommunika- 

tionsauf gaben . In der "Anwenderebene sequentiell" laufen die 
vom Anwender programmierten Programmteile fur die eigentliche 
Steuerungsauf gabe . Stdfit die Steuerung in einem dieser Pro- 
grairunteile auf einen Bewegungs- oder Positionierbef ehl , wird 

10 ein "Suspend" gesetzt, d.h. das Anwenderprogramm wird an die- 
ser Stelle unterbrochen . In diesem Fall wird ein Befehl syn- 
chron genutzt. Die Abarbeitung dieses Bewegungs- oder Positi- 
onierbefehls geschieht in einer hochstprioren "Systemebene 
getaktet" . Ein jeder Lageregler oder Interpolator, der in der 

15 "Systemebene getaktet" ablauft, fuhrt diesen Bewegungs- bzw. 
Positionierbef ehl aus . Nach Ausfuhrung des Befehls wird in 
die "Anwenderebene sequentiell" zuruckgesprungen und das 
durch "Suspend" unterbrochene Anwenderprogramm wird durch ein 
"Resume" an der gleichen Stelle fortgesetzt. Die "Systemebene 

2 0 getaktet" enthalt neben den schon erwahnten Lagereglern auch 

den Interpolations teil der Steuerung. 

Auf die niederpriorste Ebene setzt die "Anwenderebene Events" 
auf. Hier sind solche Tasks untergebracht , die auf externe 
^ 25 oder interne Ereignisse reagieren. Solche Ereignisse konnen 
beispielsweise Alarme sein. 

In einer folgenden "Anwenderebene synchrongetaktet " laufen 
synchron getaktete Anwender-Tasks ab, z.B. Reglerf unktionali- 

3 0 taten. Diese Tasks sind synchronisiert zu getakteten System- 

funktionen wie zum Beispiel Interpolator, Lageregler oder 
zyklische Buskommunikation . 

In der Darstellung gemaE FIG 3 wird in Form eines Struktur- 
bildes gezeigt, dass die Steuerung eines technischen Prozes- 
35 ses PI uber das Runtime-System RTS einer industriellen Steue- 
rung erfolgt. Die Verbindung zwischen dem Runtime- System RTS 
der Steuerung und dem technischen Prozess PI geschieht bidi- 
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rektional iiber die Ein-/Ausgange EA. Die Programmierung der 
Steuerung und damit das Festlegen des Verhaltens des Runtime- 
Systems RTS geschieht im Engineering-System ES . Das Enginee- 
ring-System ES enthalt Werkzeuge fur die Konf igurierung, Pro- 
5 jektierung und Programmierung fur Maschinen bzw. fur die 

Steuerung technischer Prozesse. Die im Engineering-System er- 
stellten Programme werden iiber den Inf ormationspf ad I in das 
Runtime -System RTS der Steuerung iibertragen. Beziiglich seiner 
Hardware -Auss tat tung besteht ein Engineering-System ES ubli- 

10 cherweise aus einem Computersystem mit Graphikbildschirm 

(z.B. Display), Eingabehilf smitteln (z.B. Tastatur undMaus), 
Prozessor, Arbeits- und Sekundarspeicher , einer Einrichtung 
fiir die Aufnahme computerlesbarer Medien (z.B. Disketten, 
CDs) sowie Anschlusseinheiten fiir einen Datenaustausch mit 

15 anderen Systemen (z.B. weiteren Computersystemen, Steuerungen 
fiir technische Prozesse) oder Medien (z.B. Internet). Eine 
Steuerung besteht iiblicherweise aus Eingabe- und Ausgabeein- 
heiten, sowie aus Prozessor und Programmspeicher . Es ist auch 
vorstellbar, dass die Steuerung eines technischen Prozesses 

2 0 PI iiber mehrere Runtime-Systeme RTS von industriellen Steue- 

rungen erfolgt. 

Die Darstellung gemaS FIG 4 zeigt das Ablauf ebenenmodell der 
industriellen Steuerung. Die Priorisierung der Ebenen wird 
^2 5 durch einen Pfeil in Richtung zur hochsten Priori tat angedeu- 
tet. Die niederpriorsten Ebenen sind die " zyklische Anwender- 
ebene" und die " sequent ielle Anwenderebene" . Diese beiden E- 
benen laufen mit der gleichen Prioritat. Deshalb sind diese 
Ebenen in der Darstellung gemaS FIG 4 durch eine gestrichelte 

3 0 Linie getrennt. Die "zyklische Anwenderebene" beinhaltet die 

"Background Task", die zykluszeitiiberwacht ist. In der "se- 
quentiellen Anwenderebene" werden die "Motion Tasks" durch- 
laufen. "Motion Tasks" sind nicht zykluszeitiiberwacht und 
dienen im Wesentlichen zur Beschreibung sequentieller Ablau- 
3 5 fe. "Motion Tasks" werden quasiparallel abgearbeitet . Gene- 
rell enthalten alle Anwender ebenen eine oder mehrere Tasks. 
Die Tasks nehmen die Anwenderprogramme auf. Die Tasks der 
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" zyklische Anwenderebene " und der "sequentiellen Anwenderebe- 
ne" werden in einem gemeinsamen Round-Robin- Zyklus abgearbei- 
tet . 

Die nachstf olgende Ebene ist die "zeitgesteuerte Anwenderebe- 
ne". Die Tasks dieser Ebene werden zeitgesteuert aktiviert. 
Die Zeitsteuerung ist einer Granularitat von Millisekunden 
einstellbar. Auf die "zeitgesteuerte Anwenderebene" folgt die 
"ereignisgesteuerte Anwenderebene". In dieser Ebene werden 
nach Erkennen eines User Interrupts so genannte "User Inter- 
rupt Tasks" aktiviert. User Interrupt Ereignisse konnen als 
logische Verknupfung von Prozessereignissen und/oder internen 
Zustanden formuliert werden. 

Die nachsthohere Ebene ist die "Anwenderebene fur System Ex- 
ceptions". In dieser "Anwenderebene fur System 
Exceptions" werden System Interrupts uberwacht, bei deren 
Eintreffen so genannte "Exceptions", d.h. Ausnahmef allbehand- 
lungen, generiert werden. In der "Anwenderebene fur System 
Exceptions" gibt es z.B. f olgende Tasks, die bei Auftreten 
eines entsprechenden System Interrupts aktiviert werden: 

a) "Time Fault Task", die beim Ansprechen von Zeituberwachun- 
gen aktiviert wird, 

b) "Peripheral Fault Task", die z.B. bei Prozess- und Diagno- 
sealarmen aktiviert wird, aber auch bei Stationsausf all o- 
der Stationswiederkehr , 

c) "System Fault Task", die bei allgemeinen Systemf ehlern ak- 
tiviert wird, 

d) "Program Fault Task", die bei Programmierf ehlern (z.B. Di- 
vision durch Null) aktiviert wird, 

e) "Time Fault Background Task", die beim Ansprechen der Zyk- 
lus zeituberwachung der Background Task aktiviert wird und 
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f) "Technological Fault Task", die bei Technologief ehlern ak- 
tiviert wird. 

Als nachstes folgt die Ebenengruppe "synchron getaktete Ebe- 
nen". Diese Ebenengruppe besitzt die hochste Prioritat im.Ab- 
lauf ebenenmodell . Die einzelnen Ebenen dieser Ebenengruppe 
konnen untereinander weitere Priorisierungen aufweisen. Die 
Ebenengruppe "synchron getaktete Ebenen" besteht aus mindes- 
tens einer Systemebene und mindestens einer Anwenderebene . 
Die Systemebenen beinhalten die Systemf unktionen wie z.B. La- 
geregler oder Interpolator. In die Anwenderebenen dieser Ebe- 
nengruppe konnen von einem Anwender flexibel Anwenderprogram- 
me (API - AP4; FIG 5) zugeladen werden. 

Fur die Taktung der "synchron getakteten Ebenen" gibt es eine 
Reihe unterschiedlicher Taktgenerierungsmoglichkeiten . Der 
Grundtakt kann z.B. aus einem internen Timer (Tl; FIG 10) 
kommen oder aus einem internen Takt (T3; FIG 10) eines Kommu- 
nikationsmediums (z.B. Profibus) oder aber der Takt kann auch 
aus einem Prozessereignis des technologischen Prozesses abge- 
leitet werden. Ein solches Prozessereignis kann z.B. die 
Taktrate (TG; FIG 10) eines Vorgangs an einer Produktionsma- 
schine oder Verpackungsmaschine sein. Anwenderebenen der Ebe- 
nengruppe "synchron getaktete Ebenen" konnen dabei basierend 
auf dem Grundtakt getaktet werden, sie konnen aber auch syn- 
chron zu einer der Systemebenen der Ebenengruppe "synchron 
getaktete Ebenen" laufen. Die Anwendertasks dieser zu einer 
Systemebene synchronen Anwenderebene haben somit eine syn- 
chrone, d.h. deterministische Beziehung zu einer vom Anwender 
flexibel festlegbaren Systemebene. Das hat den Vorteil, dass 
deterministische Reaktionen auf Systemtasks (Systemtasks lau- 
fen in den Systemebenen) , die der Anwender in seinen Anwen- 
dertasks programmiert hat, die in den Anwenderebenen der Ebe- 
nengruppe "synchron getaktete Ebenen" laufen, vom System ga- 
rantiert werden. Das heiSt z.B., dass das System garantiert, 
dass diese "synchrone Anwenderebene" entsprechend beispiel- 
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haft vor dem Interpolator aktiviert wird oder aber auch vor 
einer beliebigen anderen Systemf unktion . 

Die " zeitgesteuerte Anwenderebene", die " ereignisgesteuerte 
Anwenderebene", die " sequentielle Anwenderebene"; die "zykli- 
sche Anwenderebene" sowie die "Anwenderebene fur System Ex- 
ceptions " sind optional . 

Die Task der "zyklischen Anwenderebene" (Background Task) ist 
zykluszeitiiberwacht. Die "Motion Tasks" dagegen sind nicht 
zykluszeitiiberwacht und dienen im wesentlichen zur Beschrei- 
bung sequentieller Ablaufe. Das heiSt, das vorliegende Ab- 
lauf ebenenmodell unterstiitzt einen Anwender sowohl bei der 
Programmierung von sequentiellen Ablaufen als auch bei der 
Ereignisprogrammierung . Es konnen somit synchrone Ereignisse 
als auch asynchrone Ereignisse durch die Programmierung er- 
fasst werden. In die Anwenderebenen sind die vom Anwender er- 
stellten Anwenderprogramme (API - AP4 ; FIG 5) zuladbar. Die 
Anwenderprogramme API bis AP4 werden iiblicherweise mit Hilfe 
einer Programmierumgebung des Engineering- Systems (ES; FIG 3) 
erstellt . 

Die Darstellung gemaS FIG 5 zeigt ein Ausf iihrungsbeispiel fur 
das Zuladen von Anwenderprogramm in die Anwenderebenen. FIG 5 
zeigt exemplarisch eine Auspragung von Anwenderebenen des Ab- 
lauf ebenenmodells . Durch die drei Punkte am unteren Rand der 
Zeichnung ist dargestellt, dass auch noch weitere Anwender- 
ebenen, aber auch Systemebenen vorhanden sein konnen. Die 
Priorisierung der Ebenen wird wie im Vorangegangenen durch 
einen Pfeil in Richtung zur hochsten Prioritat angedeutet. 
Den Anwenderebenen werden die Anwenderprogramme API bis AP4 , 
am rechten Bildrand durch kleine Rechtecke angedeutet, zuge- 
ordnet. Die Zuordnung wird dargestellt durch Zuordnungspf eile 
ZPl bis ZP4. In den Anwenderebenen befinden sich Tasks, die 
die zugeladenen Anwenderprogramme API bis AP4 aufnehmen. Die- 
se Tasks werden dann nach einer gewissen Strategie (z.B. se- 
quentiell) durchlaufen bzw. abgearbeitet . Sie konnen weiter- 
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hin die Eigenschaft besitzen, dass sie lauf zeitiiberwacht 
sind . 

Die Darstellung gemaS FIG 6 zeigt ein Ausf iihrungsbeispiel fur 
den Gebrauch und den Mechanismus des Wait_f or_Condition- 
Befehls, im Ablauf ebenenmodell der erf indungsgemaEen indus- 
triellen Steuerung. Der Wait_f or_Condition-Bef ehl (in FIG 6 
dargestellt als wait_f or_cond ( ) ) wird in dieser Darstellung 
exemplarisch in der " sequentiellen Anwenderebene " verwendet. 
Der Wait_f or_Condition-Bef ehl wird in den vom Anwender er- 
stellten "Motion Tasks" MTl und MT2 verwendet, die Bestand- 
teil der "sequentiellen Anwenderebene" sind. Die "Motion 
Tasks" MTl und MT2 hangen in einem Round-Robin- Zyklus , darge- 
stellt durch den Pfeil von MTl nach MT2 und durch den abge- 
winkelten Pfeil von MT2 zu MTl. Die drei Punkte innerhalb 
dieses Pfeiles deuten an, dass noch weitere "Motion Tasks" im 
Round-Robin- Zyklus hangen konnen. Die "Motion Task" MTl ent- 
halt den Wait_f or_Condit ion-Be f ehl " wait_f or_cond (cond_l ) " , 
die "Motion Task" MT2 den Wait_f or-Condition-Bef ehl 
"wait_f or_cond (cond_2 ) " . Jeweils drei Punkte, die innerhalb 
von MTl bzw. MT2 verwendet werden, deuten an, dass neben den 
beiden Wait_f or_Condition-Bef ehlen und den drei Positionier- 
befehlen posl() bis pos3() noch weitere Befehle in den "Moti- 
on Tasks" enthalten sein konnen. 

Insgesamt besteht das in FIG 6 exemplarisch dargestellte Ab- 
lauf ebenenmodell eines Runtime-Systems fur eine industrielle 
Steuerung aus folgenden Ebenen (aufgezahlt von niedrigster 
bis hochster Priori tat) : "zyklische Anwenderebene", "sequen- 
tielle Anwenderebene" (die Tasks dieser beiden Ebenen haben 
die gleiche Prioritat, dargestellt durch die gestrichelte Li- 
nie zwischen diesen Ebenen), " zeitgesteuerte Anwenderebene", 
"ereignisgesteuerte Anwenderebene", "Anwenderebene fur Syste- 
mexceptions " , " synchron getaktete Anwenderebene 2", "syn- 
chron getaktete Anwenderebene 1", "synchron getaktete System- 
ebene 2" und als hochstpriore Ebene eine "synchron getaktete 
Systemebene 1". 
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Die Arbeitsweise des Wait_f or_Condit ion-Be f ehls wird bei- 
spielhaft an "wait_f or_cond (cond__l ) " aus der "Motion Task" 
MT1 gezeigt. 1st die "Motion Task" MT1 im Round-Robin- Zyklus 
an der Reihe, werden die Befehle der "Motion Task" MT1 solan - 
ge bedient, bis die Zeitscheibe abgelaufen ist, oder eine-Un- 
terbrechung kommt. Trifft dies zu, wird die "Motion Task" MT2 
als nachste Task im Zyklus bedient, usw. Wird in der "Motion 
Task" MT1 der wait_f or_cond (cond_l ) -Bef ehl abgearbeitet, wird 
die Bedingung cond_l uberpriift. Ist cond_l = true, also er- 
fullt, dann wird sofort der nachstf olgende Befehl pos2 ( ) aus- 
gefiihrt und eventuell weitere in MT1 vorhandene Befehle suk- 
zessive abgearbeitet, bis die Kontrolle an die nachste Task 
abgegeben wird. 

Ist die Bedingung cond_l = false, also nicht erfullt, wird 
sofort die "Motion Task" MT1 unterbrochen und im Round-Robin- 
Zyklus wird MT2 bedient. Die Bedingung cond__l wird aber in 
die " synchron getaktete Systemebene 2" eingehangt (angedeutet 
durch den durchgehenden abgewinkelten Pfeil vom 
wait_f or_cond (cond_l) -Bef ehl zu der "synchron getakteten Sys- 
temebene 2") und im Takt dieser Systemebene auf ihr Erflillt- 
sein tiberpruft. Ist die Bedingung cond__l erfullt, wird im 
Round-Robin-Zyklus die aktuelle Task verdrangt, d.h. ihr wird 
die Zeitscheibe entzogen und die Motion Task MT1 wird sofort 
unmittelbar nach dem wait_f or_cond (cond„l ) mit dem Positio- 
nierbefehl pos2 ( ) fortgesetzt. Durch den gestrichelten Pfeil 
wird der Riicksprung aus der "synchron getakteten Systemebene 
2" zum Positionierbef ehl pos2(), d.h. zur " sequentiellen An- 
wenderebene " angedeutet. 

Dadurch, dass bei Nichterf iilltsein der Bedingung des 
Wait_f or__Condition-Bef ehls die Uberprufung der Bedingung in 
einer hochprioren "synchron getakteten Systemebene" stattfin- 
det, und bei Erf iilltsein der Bedingung sofort die unterbro- 
chene "Motion Task" fortgesetzt wird, ist es einem Anwender 
moglich, bei der Programmierung von Bewegungssequenzen extrem 
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zeitkritische Applikationen mit einfachen Sprachmitteln zu 
spezif izieren . Die Performance und Deterministik wird noch 
dadurch erhoht, dass beim Uberprlifen der Bedingungen in den 
jeweiligen hochprioren " synchron getakteten Systemebenen" nur 
aktuell anstehende Bedingungen eingehangt und beriicksichtigt 
werden . 

Der hier beschriebene Mechanismus erfordert auch keinen ex- 
pliziten Event-Handler. Der groSe Vorteil aus Anwendersicht 
liegt somit darin, dass der Anwender jetzt in einem sequen- 
tiellen Ablaufprogramm auf einer relativ niedrigen Priori- 
tatsebene einer "Motion Task" in seinem Programmf luss 
hochpriore Ereignisse mit Hilfe von Programmkons trukten for- 
mulieren kann und nicht in ein anderes Programm wechseln 
muss, das er dann uber andere Mechanismen (z.B. per Hand oder 
interruptgesteuert ) auf synchrone Anwendertask abbilden muss, 
sondern er hat die Moglichkeit, in einem geschlossenen Anwen- 
derprogramm diesen Zyklus "Warten auf hochpriores Ereignis" 
und "hochpriore Reaktion" auf dieses Ereignis in einem Pro- 
gramm geschlossen zu formulieren. 

Die Bedingungen, die in einem Wait_f or_Condition-Bef ehl abge- 
fragt werden, konnen vom Anwender sehr flexibel und elegant 
formuliert werden. So kann der Anwender zur Formulierung die- 
ser Bedingungen Programmvariablen aus einem Anwenderprogramm 
verwenden oder interne GroSen der Steuerung oder er kann auch 
Prozesssignale ref erenzieren . Diese GroSen konnen dann lo- 
gisch, arithmetisch oder mit beliebigen Funktionen inhaltlich 
verkniipft werden, um daraus eine Bedingung zu formulieren. 
Neben dem hochprioren Abfragen, ob die Bedingung erfullt ist, 
kann man sich auch vorstellen, dass bei Erfiilltsein der Be- 
dingung auch noch dazugehoriger Programmcode, d.h. eine da- 
hinterliegende Reaktion, die anwenderprogrammierbar ist, 
hochprior ausgefiihrt wird. Und dass erst nach der Ausfiihrung 
dieses Programmcodes der Riicksprung in die niederpriore Ebene 
erf olgt . 
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Die Darstellung gemafi FIG 7 zeigt ein erweitertes Ausfiih- 
rungsbeispiel fiir den Gebrauch und den Mechanismus des 
Wait_f or_Condition-Bef ehls , im Ablauf ebenenmodell der erfin- 
dungsgemaSen industriellen Steuerung. Der Wait_f or_Condition- 
Befehl (in FIG 7 ebenfalls dargestellt als wait_f or_cond ( ) ) 
wird in dieser Darstellung exemplarisch in der " sequentiellen 
Anwenderebene" verwendet . Der Wait_f or_Condition-Bef ehl wird 
in den vom Anwender erstellten "Motion Tasks" MT3 und MT4 
verwendet, die Bestandteil der "sequentiellen Anwenderebene" 
sind. Die "Motion Tasks" MT3 und MT4 hangen in einem Round- 
Robin-Zyklus , dargestellt durch den Pfeil von MT3 nach MT4 
und durch den abgewinkelten Pfeil von MT4 zu MT3 . Die drei 
Punkte innerhalb dieses Pfeiles deuten an, dass noch weitere 
"Motion Tasks" im Round-Robin- Zyklus hangen konnen. Die "Mo- 
tion Task" MT3 enthalt den Wait_f or_Condition-Bef ehl 
"wait_f or_cond (cond_3 ) " , die "Motion Task" MT4 den Wait_for- 
Condition-Bef ehl "wait_f or_cond (cond_4 ) " . Jeweils drei Punk- 
te, die innerhalb von MT3 bzw. MT4 verwendet werden, deuten 
an, dass neben den beiden Wait_for_Condition-Bef ehlen und den 
Positionierbef ehlen pos4() bis pos8() noch weitere Befehle in 
den "Motion Tasks" enthalten sein konnen. Durch die program- 
miersprachlichen Konstrukte "wait_f or_cond ( ) " und 
"end_wait_f or_cond" wird eine Programmsequenz in den "Motion 
Tasks" geklammert . In der "Motion Task" MT3 sind die Befehle 
pos5() und pos6() auf diese Weise geklammert. Auch in der 
"Motion Task" MT4 wird die Verwendung von "wait_f or_cond { ) " 
und " end_wait_f or_cond" angedeutet . Durch jeweils 3 Punkte 
ist in der "Motion Task" MT4 skizziert, dass vor, innerhalb 
und nach dem "wait_f or_cond ( ) - end_wait_f or_cond" -Konstrukt 
weitere Anweisungen vorhanden sein konnen. 

Das in FIG 7 exemplarisch dargestellte Ablauf ebenenmodell ei- 
nes Run time -Systems fiir eine industrielle Steuerung besteht 
wie in FIG 6 aus folgenden Ebenen (aufgezahlt von niedrigster 
bis hochster Prioritat): "zyklische Hintergrundebene " , "se- 
quent ielle Anwenderebene" (die Tasks dieser beiden Ebenen ha- 
ben die gleiche Prioritat, dargestellt durch die gestrichelte 



200023219 



19 

Linie zwischen diesen Ebenen) , "ereignisgesteuerte Anwender- 
ebene", " zeitgesteuerte Anwenderebene" , " Anwenderebene fur 
Systemexceptions " , "synchron getaktete Anwenderebene 2", 
" synchron getaktete Anwenderebene 1", "synchron getaktete 
5 Systemebene 2" und als hochstpriore Ebene eine "synchron ge- 
taktete Systemebene 1". 

In FIG 7 wird die Arbeitsweise des Wait_f or__Condition-Bef ehls 
mit einer dazugehorigen Programmsequenz gezeigt beispielhaft 
10 an "wait_f or_cond (cond_3 ) " aus der "Motion Task" MT3 gezeigt. 
Das Uberprufen der Bedingung cond_3 und das Abarbeiten der 
dazugehorigen Programmsequenz (geklammert zwischen 
) "wait_f or_cond(cond„3 ) " und "end_wait_ f or„cond" ) erfolgen da- 

bei auf einer hoherprioren Ebene des Ablauf ebenenmodells . Die 
15 zu "wait_f or_cond (cond_3 ) " dazugehorigen Programmsequenz wird 
durch die Abfolge der Befehle pos5() und pos6() gebildet . 

1st die "Motion Task" MT3 im Round-Robin-Zyklus an der Reihe, 
werden die Befehle der "Motion Task" MT3 solange bedient, bis 
2 0 die Zeitscheibe abgelaufen ist, oder eine Unterbrechung 

kommt. Trifft dies zu, wird die "Motion Task" MT4 als nachste 
Task im Zyklus bedient, usw. Wird in der "Motion Task" MT3 
der "wait_f or.cond (cond_3 ) " -Bef ehl abgearbeitet , so wird die 
Bedingung cond_3 uberpruft. 1st cond„3 = true, also erfullt, 

2 5 dann wird der normale programmablauf fortgesetzt, d.h. als 

nachstes wird der Bef ehl pos5() ausgeftihrt und eventuell wei- 
tere in MT3 vorhandene Befehle sukzessive abgearbeitet, bis 
die Kontrolle an die nachste Motion Task abgegeben wird. 

3 0 1st die Bedingung cond_3 = false, also nicht erfullt, wird 

sofort die "Motion Task" MT3 unterbrochen und im Round-Robin- 
Zyklus wird MT4 bedient . Die Bedingung cond_3 und die Befehle 
pos5() und pos6() (als dazugehorige Programmsequenz) werden 
in der Prioritat der "synchron getakteten Systemebene 2" be- 
3 5 arbeitet (angedeutet durch den durchgehenden abgewinkelten 

Pfeil, ausgehend von der Klammer, die die Zusammengehorigkeit 
von wait_f or_cond (cond_3 ) , end_wait_f or_cond und dazugehdri- 
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ger Programmsequenz ausdruckt, hin zu der "synchron getakte- 
ten Systemebene 2"). Im Takt dieser Systemebene wird cond_3 
auf ihr Erfulltsein uberpruft. 1st die Bedingung cond_3 er- 
fiillt, wird mit der Prioritat der "synchron getakteten Sys- 
5 temebene 2" die dazugehorige Programmsequenz (hier: die Ab- 
folge der Befehle pos5() und pos6() abgearbeitet . Durch den 
gestrichelten Pfeil wird der Rucksprung aus der "synchron ge- 
takteten Systemebene 2" zum Positionierbef ehl pos7 ( ) , d.h. 
zur " sequentiellen Anwenderebene" angedeutet . 

10 

Dadurch, dass bei Nichterf ulltsein der Bedingung des 
Wait_f or_Condition-Bef ehls die Uberprufung der Bedingung in 
einer hochprioren "synchron getakteten Systemebene" stattfin- 
det, und bei Erfulltsein der Bedingung sofort eine dazugeho- 
15 rige, vom Anwender erstellbare Programmsequenz auf dieser 

hochprioren Systemebene ausgefuhrt wird, konnen sogar extrem 
zeitkritische Applikationen mit einfachen Sprachmitteln spe- 
zifiziert und durchgeflihrt werden. 

20 Ein moglicher Anwendungsf all ist die Druckmarkensynchronisa- 
tion. Dabei geht es darum, eine Druckmarke auf einem Material 
hochprior zu erkennen. Beim Erkennen dieser Druckmarke wird 
typischerweise ein Istwert erf ass t ("Latchen" z.B. eines La- 
ge- oder Geberistwertes ) . Ausgehend von diesem erfassten Ist- 
, 25 wert wird ein Korrekturwert berechnet, der dem System als u- 
^ ber lager te Bewegung aufgepragt wird. Der Vorgang Istwert- 

Erkennung, Korrekturwert-Berechnung und Durchfuhrung der u- 
berlagerten Bewegung muS in einer deterministischen Zeitdauer 
erfolgen. Deswegen muS dieser Vorgang hochprior stattfinden. 

30 

Ein weiterer Anwendungsf all ist der "schnelle Bewegungs- 
start" . Hier geht es darum, z.B. Flankenwechsel sehr schnell 
zu erkennen und daran sofort anschlieSend einen Bewegungs- 
start (z.B. Positionierbewegung) zu beginnen. Die Determinis- 
3 5 tik Erkennen eines Ereignisses und Auslosen von Folgeaktionen 
ist entscheidend fur die Produktivitat einer Maschine . Bei 
Produktionsmaschinen mussen solche zyklischen Vorgange in ei- 
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ner deterministischen Zeit, z.B. <100 ms oder <50 ms erfol- 
gen. Beim Abarbeiten der Tasks auf einer normalen Hinter- 
grundebene kann diese Deterministik nicht garantiert werden. 
Der beschriebene Mechanismus ist besonders fur einen Einsatz 
5 bei Maschinen geeignet, die periodische Maschinenzyklen auf- 
weisen. 

Die Performance wird noch dadurch erhdht, dass beim Uberpru- 
fen der Bedingungen in den jeweiligen hochprioren "synchron 
10 getakteten Systemebenen" nur aktuell anstehende Bedingungen 
eingehangt und berucksichtigt werden. 

Der hier beschriebene Mechanismus erfordert, wie schon in FIG 
6 erwahnt, keinen expliziten Event-Handler. Der groSe Vorteil 
15 aus Anwendersicht liegt somit darin, dass der Anwender jetzt 
in einem sequentiellen Ablaufprogramm auf einer relativ nied- 
rigen Prioritatsebene einer "Motion Task" in seinem Programm- 
fluss hochpriore Ereignisse mit Hilfe von Programmkonstrukten 
formulieren kann und nicht in ein anderes Programm wechseln 

2 0 muss, das er dann liber andere Mechanismen (z.B. per Hand oder 

interruptgesteuert ) auf synchrone Anwendertask abbilden muss, 
sondern er hat die Moglichkeit, in einem geschlossenen Anwen- 
derprogramm diesen Zyklus "Warten auf hochpriores Ereignis" 
und "hochpriore Reaktion" auf dieses Ereignis in einem Pro- 
^25 gramm geschlossen zu formulieren. 

Der Wait_f or_Condition-Bef ehl kann vom Anwender sehr f lexibel 
und einfach eingesetzt werden, da er als normales program- 
miersprachliches Konstrukt zur Verfiigung steht. Auch die For- 

3 0 mulierung der Bedingungen ist fur einen Anwender f lexibel und 

einfach. So kann der Anwender zur Formulierung dieser Bedin- 
gungen Programmvariablen aus einem Anwenderprogramm verwenden 
oder interne GroSen der Steuerung oder er kann auch Prozess- 
signale ref erenzieren . Diese GroSen konnen dann logisch, a- 
3 5 rithmetisch oder mit beliebigen Funktionen inhaltlich ver- 
knupft werden, urn daraus eine Bedingung zu formulieren. 
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Durch das Wait_f or_Condition-Konstrukt hat ein Anwender die 
Moglichkeit in normalen Anwenderprogramxnen fur Bewegungsse- 
quenzen, ein Anwenderprogramm temporar auf eine hohere Prio- 
ri tatsebene zu legen, urn deterministische Vorgange garantie- 
5 ren zu konnen. 

Darstellung gemaS FIG 8 zeigt das programmiersprachliche Kon- 
strukt des wait„for_condition-Mechanismus als Syntaxdiagramm . 
Die terminalen Elemente sind dabei mit abgerundeten Ecken 

10 dargestellt : "WAITFORCONDITION" , "WITH" , "DO" , 

"END_WAITFORCONDITION" und " ; " . Als Rechtecke sind die nicht- 
terminalen Elemente dargestellt: " Expressions -Bezeichnung, 

> "SCHALTER" und "ANWEISUNGSTEIL" . Die Elemente "WITH" und 

" SCHALTER" sind optional. 

15 

Darstellung gemaS FIG 9 zeigt die Verwendung des 
Wait_for_Condition-Konstruktes in einem Programmablauf . Im 
oberen Teil von FIG 9 ist die Formulierung der Bedingung "my- 
Expression" dargestellt, im unteren Teil ist gargestellt, wie 
2 0 diese Bedingung in einem Wait_f or_Condition-Konstrukt verwen- 
det wird. 

Darstellung gemaS FIG 10 zeigt in einer Schemadarstellung 
Moglichkeit en, wie der Grundtakt fur die industrielle Steue- 

2 5 rung gewonnen wird. FIG 10 zeigt exemplarisch eine Kommunika- 
^ tionstopologie, in die die Steuerung S integriert ist. Die 

Steuerung S ist durch ein Rechteck dargestellt. Durch eine 
Anschlussleitung A2 ist die Steuerung S mit dem Bus Bl ver- 
bunden, an dem liber eine Anschlussleitung Al das externe Ge- 

3 0 rat EG hangt . Uber den Bus B2 erfolgt die Verbindung zum 

technischen Prozess P2 . Der technische Prozess P2 ist am un- 
teren Bildrand durch ein Rechteck dargestellt. Uber die An- 
schlussleitung A3 ist die Steuerung S mit dem Bus B2 verbun- 
den, der wiederum uber die Anschlussleitung A4 die Verbindung 
35 zum technischen Prozess P2 herstellt. 
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Die Generierung fur den Grundtakt der Steuerung S kann aus 
unterschiedlichen Taktquellen erfolgen. So z.B. aus einer in- 
ternen Taktquelle, dargestellt durch den internen Timer T2 
der Steuerung S oder auch durch eine externe Taktquelle wie 
5 z.B. den Timer Tl, der zum externen Gerat EG gehort . Als ex- 
terne Taktquelle kann aber auch der Grundtakt eines Kommuni- 
kationsmediums dienen. Wenn der Bus B2 z.B. durch einen aqui- 
distanten Profibus realisiert wird, dann kann der Takt fur 
die Steuerung aus dem Grundtakt dieses Busses gewonnen wer- 

10 den. In FIG 10 ist dies dargestellt dadurch, dass der Timer 
T3 direkt an der Anschlussleitung A3 positioniert ist, und 
diese Anschlussleitung A3 stellt die Verbindung zum Bus B2 
her. Die Steuerung hangt somit als Slave am Bus und kann di- 
rekt den Bustakt verwenden . Weiterhin kann als externe Takt- 

15 quelle ein Taktgeber TG dienen, der im technischen Prozess P2 
integriert ist. Ein Taktgeber TG in einem technischen Prozess 
kann z.B. der Arbeitstakt einer Produktionsmaschine oder Ver- 
packungsmaschine sein. In der Darstellung gemafi FIG 10 sind 
als Kommunikationsmedien beispielhaft Busverbindungen darge- 

20 stellt. Es konnen aber als Kommunikationsmedien aber auch 
Ring-, Stern- oder andere Verbindungsarten gewahlt werden, 
auch wireless-Verbindungen. Aus diesen Verbindungssystemen 
kann dann der oben genannte Grundtakt abgeleitet werden. 
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Patentanspruche 

1. Verfahren zum Betrieb einer industriellen, mit einem Run- 
time-System (RTS) ausgestatteten Steuerung (S) , insbesondere 

5 fur Produktionsmaschinen, 

d a d u r c h gekennzeichnet, 

dass Mechanismen bereitgestellt sind, die es einem Anwender 
ermoglichen im ProgrammfluS auf eine beliebige Bedingung zu 
warten, wobei bei Erfulltsein der Bedingung der ProgrammfluS 
10 unmittelbar f ortgesetzt wird, bei Nichterf iilltsein" der Bedin- 
gung der ProgrammfluS solange angehalten wird, bis das Er- 
^ fulltsein der Bedingung festgestellt wird, wobei beim Warten 

('£ auf das Erfulltsein der Bedingung die Prioritat der Bedin- 

gungsuberprufung im Vergleich zur aktuellen Taskprioritat er- 
15 hoht wird. 

2. Industrielle Steuerung nach Anspruch 1, 
dadurch gekennzeichnet, 

dass nach dem Erfulltsein der Bedingung die. folgende Pro- 
20 grammsequenz bis zu einem expliziten Ende hochprior bearbei- 
tet wird, wobei nach dem expliziten Ende der Programmsequenz 
die alte Taskprioritat wieder aufgenommen wird. 

3. Industrielle Steuerung nach Anspruch 1 oder 2, 
^25 dadurch gekennzeichnet, 

^ dass fur die Formulierung der Bedingungen ProzeSsignale 

und/oder interne Signale der Steuerung und/oder Variablen aus 
Anwenderprogrammen (API - AP4) verwendet werden. 

30 4. Industrielle Steuerung nach einem der vorstehenden Ansprii- 
che, 

dadurch gekennzeichnet, 

dass die Bedingungen logische und/oder arithmetische und/oder 
beliebige funktionelle Verkniipf ungen enthalten. 
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5. Industrielle Steuerung nach einem der vorstehenden Ansprii 
che, 

dadurch gekennzeichnet, 

dass ein Anwenderprogramm (API - AP4) fur den Betrieb der 

Steuerung mehr als einen solchen Mechanismus enthalt. 

6 . Industrielle Steuerung nach einem der vorstehenden Ansprii 
che, 

dadurch gekennzeichnet, 

dass es mehrere Anwenderprogramme (API - AP4) beim Betrieb 

der Steuerung geben kann, die diese Mechanismen enthalten. 

7 . Industrielle Steuerung nach einem der vorstehenden Ansprii 
che, 

dadurch gekennzeichnet, 

dass der jeweilige Mechanismus einem Anwender in einem Anwen 
derprogramm (API - AP4) als iibliches programmiersprachliches 
Konstrukt zur Verfiigung steht. 

8. Industrielle Steuerung zur Durchfiihrung des Verfahrens 
nach einem der vorstehenden Anspriiche, 

dadurch gekennzeichnet, 

dass das Runtime-System (RTS) der Steuerung (S) ein Ablauf- 
ebenenmodell enthalt, das mehrere Ablaufebenen unterschiedli- 
chen Typs mit unterschiedlicher Prioritat aufweist, wobei 
folgende Ablaufebenen vorgesehen sind: 

a) eine Ebenengruppe mit synchron getakteten Ebenen, beste- 
hend aus mindestens einer Systemebene und mindestens ei- 
ner Anwenderebene , wobei die Ebenen dieser Ebenengruppe 
untereinander eine Prior isierung aufweisen konnen, 

b) einer Anwenderebene fiir Systemexceptions , 

c) einer zeitgesteuerten Anwenderebene 

d) einer ereignisgesteuerten Anwenderebene 
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e) einer sequentiellen Anwenderebene 

f) einer zyklischen Anwenderebene, 

5 wobei Anwenderebenen der Ebenengruppe a) optional synchron zu 
einer der Systemebenen der Ebenengruppe a) laufen konnen. . 

9. Industrielle Steuerung nach Anspruch 8, 
dadurch gekennzeichnet, 

10 dass der Grundtakt des Ablauf ebenenmodells aus einem internen 
Timer (T2) oder aus einem internen Takt (T3) eines Kommunika- 
tionsmediums oder aus einem externen Gerat (EG) oder von ei- 
{Jt ner Grofie (TG) , die zum technologischen ProzeS (Pi, P2 ) ge- 
hort abgeleitet wird. 

15 

10. Industrielle Steuerung nach Anspruch 8 oder Anspruch 9, 
dadurch gekennzeichnet, 

dass die zeitgesteuerte Anwenderebene, die ereignisgesteuerte 
Anwenderebene, die sequentielle Ablauf ebene, die zyklische 

2 0 Hintergrundebene und die Anwenderebene fur Systemexceptions 

optional sind . 

11. Industrielle Steuerung nach Anspruch 8, 9 oder 10, 
dadurch gekennzeichnet, 

.25 dass die synchronen Ebenen zum Grundtakt iibersetzt und/oder 
untersetzt und/oder im Verhaltnis 1:1 getaktet sind. 

12. Industrielle Steuerung nach Anspruch 8, 9, 10 oder 11, 
dadurch gekennzeichnet, 

3 0 dass weitere priorisierende Schichtungen innerhalb der Ab- 

lauf ebenen vorgesehen sind. 

13. Industrielle Steuerung nach Anspruch 8, 9, 10, 11 oder 
12, 

35 dadurch gekennzeichnet, 

dass optional Anwendertasks beim Systemhochlauf und/oder beim 
Systemrunterf ahren durchlaufbar sind. 
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14. Industrielle Steuerung nach Anspruch 8, 9, 10, 11 , 12 o- 
der 13, 

dadurch gekennzeichnet, 

dass in die Anwenderebenen Anwenderprogramme (API - AP4) lad- 
bar sind, die je nach Typ der Anwenderebene zyklusorientiert 
oder sequentiell programmiert sind. 
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Zusammenf assung 

Verfahren zum Betrieb einer industriellen Steuerung 

5 Es werden Mechanismen zum Betrieb einer industriellen, mit 

einem Run time -System (RTS) ausgestatteten Steuerung (S) , ins- 
besondere fur Produktionsmaschinen bereitges tellt sind, die 
es einem Anwender ermoglichen im Programmf luss auf eine be- 
liebige Bedingung zu warten, wobei bei Erfulltsein der Bedin- 

10 gung der Programmf luss unmittelbar fortgesetzt wird, bei 

Nichterfulltsein der Bedingung der Programmf luss solange an- 
gehalten wird, bis das Erfulltsein der Bedingung festgestellt 
wird, wobei beim Warten auf das Erfulltsein der Bedingung die 
Prioritat der Bedingungsuberpruf ung im Vergleich zur aktuel- 

15 len Taskprioritat erhoht wird. Bei Erfulltsein der Bedingung 
wird eine definierte Programmsequenz bis zu einem expliziten 
Ende hochprior bearbeitet wird, wobei nach dem expliziten En- 
de der Programmsequenz die alte Taskprioritat wieder aufge- 
nominen wird. 

20 

FIG 6 
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Systemebene hochprior 



Anwenderebene fur asynchrone Fehler 
Anwenderebene Events 



Anwenderebene zeitgesteuert 



Anwenderebene freier Zyklus 
Systemebene Hintergrund 



Systemebene getaktet 
Anwenderebene synchrongetaktet 
Anwenderebene Events 



Anwenderebene sequentiell 
Systemebene Hintergrund 



— ES 



—I 

I 

— RTS 



2000P23219 DE 01 



2/6 



Synchron getaktete Ebenen 



Anwenderebene fur Systemexceptions 
ereignisgesteuerte Anwenderebene 
zeitgesteuerte Anwenderebene 



sequentielle Anwenderebene 
zyklische Anwenderebene 



FIG 4 



synchron getaktete Anwenderebene 1 
synchron getaktete Anwenderebene 2 
synchron getaktete Anwenderebene 3 
synchron getaktete Anwenderebene 4 
ereignisgesteuerte Anwenderebene 
zeitgesteuerte Anwenderebene 



FIG 5 
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synchron getaktete 
Systemebene 1 



synchron getaktete 
Systemebene 2 



synchron getaktete 
Anwenderebene 1 



synchron getaktete 
Anwenderebene 2 



Anwenderebene fur 
Systemexceptions 



ereignisgesteuerte 
Anwenderebene 



zeitgesteuerte 
Anwenderebene 



Sequentielle Anwenderebene 
-MT1 




r 



MT2 



pos 3 ( ) 

wait_for_cond(cond_2) 



zyklische Anwenderebene 



FIG 6 
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synchron getaktete 
Systemebene 1 



synchron getaktete 
Systemebene 2 



synchron getaktete 
Anwenderebene 1 



synchron getaktete 
Anwenderebene 2 



Anwenderebene fur 
Systemexceptions 



ereignisgesteuerte 
Anwenderebene 



zeitgesteuerte 
Anwenderebene 



Sequentielle Anwenderebene 



MT3 



pos 4 ( ) 

wait_for_cond(cond_3) 
pos 5 ( ) 
pos 6 ( ) 

end_wait_for_cond 
pos7() -* 



• 
• 



MT4 



pos 8 ( ) 

wait_for_cond(cond_4) 
end wait for cond 



zyklische Anwenderebene 



FIG 7 
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WAITFORCONDITION 



Expressions- 
Bezeichnung 



-(with)- 



SCHALTER 



Anweisungsteil 



END WAITFORCONDITION 



FIG 8 



IMPLEMENTAT ION 
EXPRESSION myExpxession 

//Vereinbarung lokaler Variablen moglich 
VAR 

myLoc : WORD 
END_VAR 

myLoc :=%IW10 & 16#ff00; 

//Dies ist eine mit WAITFORCONDITION auszuwertende 
//Bedingung (Riickgabewert der Funktion) . Wenn FALSE, 
//wird die betreffende Task ausgesetzt, bis Bedingung 
//TRUE ergibt. 

myExpxession :=myloc <> 16#0100; 
END EXPRESSION 



PROGRAM myProgram 

//Aufruf des Befehls mit Namen der Expression 
WAITFORCONDITION myExpression WITH TRUE DO 
// hier mind, eine Anweisung, wird hochprior ausgefuhrt 
END_WAI TFORCOND I T ION ; 

END_PROGRAM 
END IMPLEMENTATION 
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